На сайте VMware Labs появилась очень нужная многим администраторам вещь - генератор сертификатов VMCA Certificate Generator. С помощью этой утилиты можно получить сертификаты, подписанные центром сертификации VMware Certificate Authority (VMCA) со стороны сервера VMware vCenter / Platform Services Controller (PSC), и использовать их в сервисах VMware или любых других сторонних сервисах.

Это может потребоваться, когда у вас в компании нет собственного Certificate Authority (например, у вас маленький бизнес или своя лаба), чтобы подписывать сертификаты, но, в то же время, вам нужно генерировать сертификаты для ваших служб.

Полученные сертификаты можно использовать для таких продуктов, как vRealize Suite и NSX, а также других из корпоративной линейки VMware. Надо понимать, что если вы доверяете корневому сертификату VMCA, то вы доверяете и всем службам, использующим данные сертификаты.

Срок действия сертификатов вы не можете настраивать, это зависит от версии vCenter. Для vCenter 7.0 вы получите сертификаты сроком действия 2 года.

VMCA Certificate Generator поставляется в виде .jar-файла, который нужно открывать по правой кнопке и выбирать пункт меню "open with jar Launcher", либо надо выполнить следующую команду:

java -jar vmca-cert-generator.jar

Выглядит интерфейс утилиты следующим образом:

Для соединения с vCenter/PSC нужно заполнить данные доступа к серверу и данные сертификата, который необходимо выписать. Далее нужно нажать кнопку "START". Начнется процесс создания сертификата с выводом лога, после чего станет активна кнопка "DOWNLOAD", по нажатию на которую вы получите zip-архив со следующим содержимым:

• certool.cfg - конфиг настроек сертификата
• root.cer - корневой VMCA-сертификат
• Ключи private.key и public.key
• .cer - сертификат в формате X509
• .pfx - зашифрованный сертификат в формате PKCS#12 (пароль для него будет тот, который вы указывали в форме выше)
• chain-with-privkey.pem - цепочка сертификата, включая приватный ключ
• chain-without-privkey.pem - цепочка сертификата без приватного ключа

Разные сервисы требуют сертификаты в различных форматах, поэтому данный комплект очень полезен - вам не нужно будет конвертировать сертификаты.

Для работы генератора вам потребуется среда Java Runtime (протестирована версия 1.8.x) и сервер vCenter 6.7 / 7.0. Скачать VMCA Certificate Generator можно по этой ссылке.

Как многие из вас знают, в последние пару лет очень сильно увеличилось число и масштаб атак, связанных с уязвимостями в аппаратном обеспечении. Наибольшую известность получили уязвимости Meltdown и Spectre, которые были обнаружены в процессорах Intel.

Самый неприятный момент, связанный с подобного рода уязвимостями - это то, что поскольку они связаны с аппаратной частью процессоров на самом низком уровне, то, во-первых, ее сложнее исправить и доставить конечным пользователям, а, во-вторых, неправильное обновление, закрывающее эти дырки, может вызвать различные побочные эффекты.

Так, например, было с производительностью серверов VMware ESXi, когда производители ОС совместно с Intel выпустили соответствующие обновления, а VMware выпустила закрывающий уязвимость патч. Сам патч тогда пришлось отозвать и ждать нового, а ведь это потраченного время администраторов, время пользователей и время, в течение которого существует угроза безопасности инфраструктуры предприятия.

Поэтому производители процессоров, совместно с вендорами платформ виртуализации, сейчас уделяют этому моменту особое внимание. Конечно же, в этом направлении работает и AMD, которая активно внедряет следующие технологии:

• Secure Encrypted Virtualization (SEV) - первая версия технологии, анонсированная в 2016 году. Она позволяет изолировать виртуальные машины от гипервизора, со стороны которого может быть угроза безопасности при его компрометации. Если гипервизор попытается считать память гостевой ОС, он увидит только зашифрованные данные.
• SEV-ES (Encrypted State) - вторая версия технологии, представленная в 2017 году. Она дополняет защиту памяти гостевой ОС шифрованием регистров CPU гостевой ОС. Таким образом, гипервизор не может видеть регистры процессора, активно используемые виртуальной машиной.
• SEV-SNP (Secure Nested Paging) - следующее поколение технологии, которое было анонсировано в этом году. Оно добавляет функции аппаратной безопасности для контроля над интеграцией памяти гостевых ОС, что защищает от таких атак, как data replay, memory re-mapping и других (подробнее тут и на картинке ниже).

Надо начать с того, что у VMware уже есть защита памяти и данных гостевой ОС на уровне платформы (а в самих ОС тоже есть средства защиты памяти и процессора), но, само собой, эти механизмы на надежны на 100%, потому что ключевой компонент платформы - гипервизор, обладает очень широкими полномочиями (в виду необходимости), и при его компрометации ничего особо не поможет. Поэтому самое разумное - это поддержать подход изоляции ВМ от гипервизора на аппаратном уровне. Он, кстати, называется Trusted Execution Environment (TEE).

Подход AMD заключается в том, что они добавляют специальный Secure Processor, маленький сопроцессор, интегрированный в основной чип CPU, который является основой безопасности и поддерживает операции шифрования, в том числе и для SEV-ES.

Первое поколение EPYC CPU поддерживало хранение только 15 ключей шифрования, но следующее поколение уже поддерживает более 500. Один из таких ключей используется для гипервизора, а остальные - для гостевых систем.

Для чего вообще нужно защищать регистры процессора гостевых систем? Очень просто - когда виртуальная машина переключает контекст исполнения (меняет процессор), гипервизор получает ресурсы CPU обратно, вместе с содержимым регистров. А в них может храниться много "полезного" для злоумышленника - например, ключи для расшифровки дисков гостевой системы.

Работает механизм ключей так - гостевая ОС запрашивает у процессора с поддержкой SEV ключ шифрования для памяти, а SEV-ES расширяет его и на регистры процессора тоже, после чего гостевая ОС может безопасно использовать память и регистры, не беспокоясь что гипервизор или другие ВМ, изолированные в рамках процессов VMX, считают их содержимое. Очевидно, что гостевая ОС тоже должна поддерживать реализацию SEV-ES (поэтому надо читать соответствующую документацию к ним, чтобы узнать о поддержке).

Самым большим минусом использования технологии SEV-ES является невозможность поддержки таких техник, как vMotion, Memory Snapshots, Guest Integrity, Hot Add, Suspend & Resume, Fault Tolerance и горячих клонов - ведь для их реализации гипервизор должен иметь прямой доступ к памяти гостевых систем. В то же время надо отметить, что это не ограничение от AMD, которая заявляет, что SEV поддерживает live migration и прочее, а ограничение реализации от VMware.

В большинстве производственных окружений невозможность применения этих технологий будет ограничивать использование SEV-ES только системами, требующих наивысшего уровня защищенности.

С другой стороны, например, недавно вышедшее решение vSphere with Tanzu не использует vMotion для машин с контейнерами виртуализованных приложений - они просто выключаются на одном хосте и включаются на другом, то есть здесь есть перспективы применения SEV-ES.

Также использованием технологии SEV-ES можно управлять в пакетном режиме сразу для нескольких тысяч виртуальных машин через интерфейс PowerCLI, что особенно актуально для контейнеров Tanzu. На данный момент VMware еще не опубликовала официальный референс по командлетам для SEV-ES, ждем.

Ну и недавно VMware выпустила интересное видео, рассказывающее о первой имплементации технологии SEV-ES в платформе VMware vSphere 7 Update 1:

Как итог можно отметить, что пока такие технологии, как Secure Encrypted Virtualization имеют достаточно узкое применение ввиду их ограничений. Однако это лишь первые шаги, которые производители процессоров делают совместно с вендорами платформ виртуализации, чтобы защитить ИТ-среду предприятия он новой волны атак на программно-аппаратную инфраструктуру датацентра. Дальше все это будет развиваться, будет и поддержка AMD SEV-SNP, что уже будет существенно уменьшать поверхность возможных атак.

На этой неделе компания VMware опубликовала новость об окончании поддержки браузера Internet Explorer 11. Шаг этот совершенно логичен, поскольку сама Microsoft анонсировала окончание поддержки Explorer 11 продуктами линейки MS365 (вот официальный guidance). Пользователям предлагается мигрировать на браузер Edge.

Поддержка IE 11 будет прекращена всеми активными версиями vSphere Client, начиная со следующего за vSphere 7.0 Update 1 релиза платформы. На самом деле, де-факто IE 11 был в опале уже довольно давно, и его использует менее 2% пользователей согласно статистике (большинство, конечно же, корпоративные). Одна из причин, помимо качества предоставляемого сервиса (стабильность и производительность) - недостаточная защищенность (смотрим пример от января этого года).

Также IE не поддерживает новые возможности HTML5, не имеет полной поддержки CSS, WebAPI и WebGL. Работает vSphere Client в IE намного хуже, чем в других современных браузерах. Также там возникает много ошибок, работая с которыми VMware тратит много ресурсов.

Таким образом, скоро IE 11 вылетит из списка совместимых браузеров для vSphere Client. Случится это для всех версий с выходом vSphere 7 Update 2. В общем, имейте в виду.

Недавно мы писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1, а также обновленных функциях платформы для организации кластеров хранилищ VMware vSAN 7 Update 1.

Одной из новых возможностей VMware vSphere 7 U1 стала служба vSphere Clustering Service (vCLS), которая позволяет организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter.

Как вы знаете, кластер HA/DRS очень зависит от постоянной доступности сервисов vCenter, который является критическим звеном виртуальной инфраструктуры. Поэтому для него организовывают такие сервисы, как vCenter Server High Availability (VCHA), но и они не идеальны. Также проблема наблюдается при масштабировании кластеров в больших окружениях, которые объединяют онпремизные и облачные площадки, где масштабируемость vCenter является серьезной проблемой.

Учитывая это, VMware придумала такую штуку - сажать на хосты кластера 3 служебных агентских виртуальных машины, составляющих vCLS Control Plane, которые отвечают за доступность кластера в целом:

Таких виртуальных машин три в кластере, где 3 или более хостов, и две, если в кластере два хоста ESXi. Три машины нужны, чтобы обеспечивать кворум (2 против 1) в случае принятия решения о разделении кластера.

Три этих виртуальных машин следят друг за другом и оповещают об этом кластерные службы vCenter:

Это самокорректирующийся механизм, что значит, что если одна из агентских машин становится недоступной или выключенной, то службы vCLS пытаются самостоятельно наладить работу ВМ или включить ее.

Есть 3 состояния служб vCLS:

• Healthy – как минимум 1 агентская ВМ работает в кластере, чтобы обеспечить доступность кластера развертываются 3 ВМ для кворума.
• Degraded – как минимум одна агентская машина недоступна, но DRS продолжает функционировать и исполнять свою логику. Такое может, например, произойти при передеплое служебных машин vCLS или после какого-то события, повлиявшего на их "включенность".
• Unhealthy – логика DRS не выполняется (балансировка или размещение ВМ), так как vCLS control-plane недоступна (то есть ни одной агентской ВМ не работает).

Легковесные машины-агенты исполняются на хостах ESXi и лежат на общих хранилищах, если общие хранилища недоступны - то на локальных дисках. Если вы развернули общие хранилища после того, как собрали кластер DRS/HA (например, развернули vSAN), то рекомендуется перенести агентские ВМ с локальных хранилищ на общие.

Сама гостевая ОС агентских ВМ очень легковесная, используется Photon OS следующей конфигурации:

Диск в 2 ГБ - это тонкий диск, растущий по мере наполнения данными (thin provisioned). Эти машины не имеют своего нетворка, а также не видны в представлении Hosts and Clusters в клиенте vSphere.

Агентские ВМ можно увидеть в представлении VMs and Templates где есть папка vCLS:

Обратите внимание, написано, что для агентских ВМ управление питанием производится со стороны служб vCLS. Если вы попытаетесь выключить эти ВМ, то будет показано следующее предупреждение:

При переводе кластера в режим обслуживания vCLS сам заботится о миграции агентских ВМ с обслуживаемых серверов и возвращении их обратно. Для пользователя это происходит прозрачно. И, конечно же, лучше не выключать эти ВМ вручную и не переименовывать папки с ними.

Жизненный цикл агентских ВМ обслуживается со стороны vSphere ESX Agent Manager (EAM).

EAM отвечает за развертывание и включение агентских ВМ, а также их пересоздание, если с ними что-то произошло. В анимации ниже показано, как EAM восстанавливает ВМ, если пользователь выключил и/или удалил ее:

Важный момент для разработчиков сценариев PowerCLI - это необходимость обрабатывать такие ВМ, чтобы случайно не удалить их. Например, ваш скрипт ищет неиспользуемые и забытые ВМ, а также изолированные - он может по ошибке принять машины vCLS за таковые и удалить, поэтому их надо исключать в самом сценарии.

В интерфейсе vSphere Client список агентских ВМ можно вывести в разделе "Administration > vCenter Server Extensions > vSphere ESX Agent Manager".

У агентских ВМ есть свойства, по которым разработчик может понять, что это они. В частности:

• ManagedByInfo
  • extensionKey == "com.vmware.vim.eam"
  • type == "cluster-agent"

• ExtraConfig keys
  • "eam.agent.ovfPackageUrl"
  • "eam.agent.agencyMoId"
  • "eam.agent.agentMoId"

Основное свойство, по которому можно идентифицировать агентскую ВМ, это HDCS.agent, установленное в значение "true". В Managed Object Browser (MOB) выглядит это так:

Ну и напоследок - небольшое демо технологии vSphere Clustering Service:

Как вы знаете, у компании VMware есть клиент для управления отдельными хостами VMware ESXi, который называется VMware ESXi Embedded Host Client. Последний раз обновлялся он в феврале прошлого года, и VMware не уделяет ему никакого внимания.

Между тем, VMware рассказала о том, что в ближайшем будущем эта недоработка будет исправлена. Дело в том, что интерфейс существующего хост-клиента построен на базе фреймворка Angular JS web framework, последний стабильный релиз которого 1.7 вошел в фазу long term support 30 июня 2018 года. Начиная с 1 января 2022 года, Angular JS больше не будет поддерживаться со стороны Google.

Последующие релизы фреймворка (Angular 4 и более поздние) не будут совместимы с Angular JS. Соответственно, VMware пора уходить с технологии, которая скоро устареет. Поэтому Host Client переедет с технологии Angular JS на последнюю версию Angular web framework (сейчас это Angular 9).

Вместе с этим произойдет и удаление компонентов, которые зависят от Angular JS, а также апдейт основного графического фреймворка Clarity на третью версию.

Собственно, это та причина, по которой VMware не обновляет текущий ESXi Host Client. Этот клиент больше не будет получать новых возможностей, но будет получать некоторые текущие обновления.

А вот новый клиент выйдет уже как Single host managing UI (он же ESXi UI) во второй половине 2021 года.

Для старого клиента будут предоставляться только следующие обновления:

• Только доступность самых критичных блоков функциональности и обеспечение апдейтов безопасности
• Поддержка текущих рабочих процессов, для которых нет альтернативы
• Решение проблем с производительностью
• Все прочие проблемы, которые могут привести к оттоку пользователей клиента

Новый ESXi UI будет являться частью ESXi Client и будет построен на базе Clarity 3 в его составе. Соответственно все процессы управления отдельным хостом ESXi будут аналогично таковым в рамках кластера под управлением vCenter.

VMware выпустит этот клиент как только сможет реализовать там все основные рабочие процессы и операции жизненного цикла текущего Host Client, включая развертывание ВМ, конфигурацию, мониторинг, решение проблем и обновление. Это займет время, поэтому нам и ждать полноценной версии где-то год.

Но первую версию нового клиента с базовой функциональностью нам обещают уже в первом квартале следующего года.

Недавно мы писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1, а также решения для создания отказоустойчивых хранилищ на базе хостов VMware vSAN 7 Update 1. В статье о vSAN мы упоминали о том, что VMware расширяет службы vSAN Native File Services за счет поддержки протокола SMB. Он интегрирован с Microsoft Active Directory и поддерживает аутентификацию Kerberos. Давайте посмотрим на эти возможности подробнее.

Во-первых, начнем с небольшого обзора от Дункана Эппинга:

Поддержка протокола SMB была введена в vSAN не просто так - целью была поддержка постоянных томов read-write many (RWM) volumes для cloud native applications (то есть современных приложений, исполняемых в контейнерах Docker под управлением Kubernetes). Для доступа поддерживаются хранилища SMB версий v2.1, так и v3 (SMB v1 находится в статусе Deprecated).

SMB-хранилища, создаваемые в vSAN, могут быть доступны из Windows-клиентов (версии 8/2012+) и Mac-клиентов (OS 10 и позднее). Это, совместно с поддержкой Active Directory, делает SMB-хранилища отличным вариантом для:

• VDI-сценариев, где пользователи предпочитают перенаправление каталога user/home на выделенную файловую шару.
• Файловые ресурсы, обслуживающие различные топологии (например, удаленные офисы или филиалы), могут управляться напрямую из vSAN, без необходимости иметь отдельную ВМ для предоставления общего доступа к папкам.

Файловые шары видны через Windows MMC, где администраторы могут: 

• Смотреть число клиентских соединений к шаре
• Смотреть число открытых файлов
• Управлять разрешениями и безопасностью (в стиле NTFS)
• Закрывать клиентские соединения
• Закрывать открытые файлы

Как мы писали выше, поддерживается и протокол аутентификации Kerberos, который предотвращает доступ NFS-клиентов через более уязвимые методы доступа, такие как auth_sys. vSAN поддерживает 3 модели аутентификации:

• KRB5, который проводит только безопасную аутентификацию (только на NFS v4.1)
• KRB5I, включая аутентификацию и проверку контрольных сумм
• KRB5P, включая аутентификацию, проверку контрольных сумм и шифрование

Надо отметить, что несмотря на то, что VMware vSphere 7 U1 поддерживает кластеры до 64 хостов, службы Native File Services поддерживают доступ до 32 хостов к файловым шарам.

Теперь службы Skyline Health (ранее это называлось "vSAN Health") содержат дополнительные хэлсчеки, включая file server health и share health:

Тут есть три основных типа проверок:

• Проверки Infrastructure health checks - развернута ли машина FSVM и демон VDFS, а также есть ли файловая система root на хосте. Если чего-то из этого нет, то проверка показывает красный сигнал.
• Проверки File Server Health checks показывают, все ли в порядке с файловым сервером на отдельных хостах, и есть ли там файловая система root. Если что-то из этого не в порядке - показывается красный сигнал.
• Проверки Share Health отвечают за статус объектов файловых шар. Если служба протокола не работает для данного объекта, то показывается красный сигнал. Также могут быть оповещения для шар - и тогда будет желтый.

Для файловых шар SMB появился мониторинг производительности в интерфейсе vSAN UI. Можно смотреть за пропускной способностью (throughput), IOPS, задержками (latency) на уровне отдельной шары в реальном времени. Можно увеличивать временное окно просмотра для отдельных метрик. Также эти метрики доступны через API, поэтому такие продукты, как vRealize Operations также будут их использовать.

Доступную емкость SMB-хранилищ можно отслеживать через vSAN Capacity view:

Если вы нажмете на ссылку File shares overview в левом нижнем углу, то сможете открыть просмотр емкости на уровне отдельных шар. На картинке ниже представлен микс из SMB и NFS хранилищ, столбики в Usage/Quota показывают жесткие аппаратные квоты с цветовым кодированием заполненности:

Ну и напоследок небольшой обзор VMware vSAN File Services от VMware:

На сайте проекта VMware Labs вышла очередная полезность - сценарий для интеграции VMware vRealize Network Insight (vRNI) и VMware HCX. Напомним, что vRNI - это решение для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений, а HCX - продукт для миграций с различных опремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на базе VMware vCloud.

С помощью данного скрипта администраторы VMware vSphere могут упростить и ускорить процесс миграции виртуальных машин. Сначала сценарий за счет vRNI обнаруживает приложение и его границы использования сети и ресурсов в рамках виртуальной машины, после чего создает под него структуры внутри самого vRNI.

Затем эти vRNI application constructs интегрируются в объекты HCX Mobility Groups, экономя время на ручное создание этих сущностей. После подготовки объектов вы можете начать сам процесс миграции виртуальных машин.

Для работы сценария оба продукта vRNI и HCX должны иметь лицензию Enterprise, также у вас должны быть установлены модули PowervRNI and the PowerCLI HCX.

Пример использования сценария:

$vrni_pw = ConvertTo-SecureString 'admin' -AsPlainText -Force
$hcx_pw = ConvertTo-SecureString 'VMware1!' -AsPlainText -Force
./sync-vrni-to-hcx.ps1 -vRNI_Server 10.196.164.134 -vRNI_Username admin@local -vRNI_Password $vrni_pw -HCX_Server hcxe.vrni.cmbu.local -HCX_Username hcx@cmbu.local -HCX_Password $hcx_pw -HCX_DestinationVC vc-pks.vrni.cmbu.local -HCX_DestinationCloud hcxc.vrni.cmbu.local
[03-05-2020_05:19:59] Connecting to vRealize Network Insight..
[03-05-2020_05:20:01] Retrieving all applications..
[03-05-2020_05:20:20] Found application: 'onprem_imagic' with 6 VMs
[03-05-2020_05:20:22] Found application: '3TierApp02' with 1 VMs
[03-05-2020_05:20:25] Found application: 'HIVE Training' with 1 VMs
[03-05-2020_05:20:27] Found application: 'VDI Pool 1' with 8 VMs
[03-05-2020_05:20:29] Found application: 'app_mcclanahanc' with 2 VMs
[03-05-2020_05:20:31] Found application: 'Top-Video' with 15 VMs
[03-05-2020_05:20:33] Found application: 'F5-3TierApp05' with 5 VMs
[03-05-2020_05:20:34] Connecting to VMware HCX..
[03-05-2020_05:20:48] Created Mobility Group: 'onprem_imagic_2020-03-05'
[03-05-2020_05:20:49] Created Mobility Group: '3TierApp02_2020-03-05'
[03-05-2020_05:20:50] Created Mobility Group: 'HIVE Training_2020-03-05'
[03-05-2020_05:20:51] Created Mobility Group: 'VDI Pool 1_2020-03-05'
[03-05-2020_05:20:52] Created Mobility Group: 'app_mcclanahanc_2020-03-05'
[03-05-2020_05:20:53] Created Mobility Group: 'Top-Video_2020-03-05'
[03-05-2020_05:20:54] Created Mobility Group: 'F5-3TierApp05_2020-03-05'

Инструкции по использованию скрипта приведены здесь, а сам он доступен по этой ссылке на GitHub.

Компания VMware, сразу после анонсов новых версий VMware vSAN 7 Update 1 и VMware Cloud Foundation 4.1, объявила о скорой доступности для загрузки новой версии своей серверной платформы виртуализации VMware vSphere 7 Update 1.

Основной фишкой первого пакета обновления седьмой версии vSphere стал, конечно же, финальный выпуск платформы VMware vSphere with VMware Tanzu, объединяющей миры виртуальных машин и контейнеризованных приложений в рамках инфраструктуры предприятия.

Вот небольшой обзор платформы VMware vSphere with Tanzu, о первых объявлениях компонентов которой мы уже писали тут и тут (а о текущей версии рассказано в блоге VMware):

Нововведения vSphere 7 U1 разбиты на 3 блока:

• Инфраструктура для разработчиков (контейнеры)
• Продолжение масштабирования возможностей платформы
• Упрощение операций администраторов

Итак, давайте посмотрим, что нового в VMware vSphere 7 Update 1:

1. Инфраструктура для разработчиков

Здесь VMware добавила следующие важные возможности:

• Служба Tanzu Kubernetes Grid (TKG) - о ней мы упоминали вот тут. Она позволяет администраторам развертывать Kubernetes-окружения и управлять их составляющими с помощью решения для кластеров Tanzu Kubernetes. Делается это теперь за минуты вместо часов. Также TKG идет в соответствии с политиками upstream Kubernetes, что позволяет сделать процесс миграции максимально бесшовным.
• Bring Your Own Networking - пользователи могут выбирать, какой сетевой стек использовать для кластеров Tanzu Kubernetes. Можно использовать традиционную инфраструктуру на базе vSphere Distributed Switch (vDS) для конфигурации, мониторинга и администрирования виртуальных машин и кластеров Kubernetes. Новый Networking for Tanzu Kubernetes clusters позволяет использовать и решения VMware NSX. Также можно использовать Antrea для максимальной производительности внутренней сети для сервисов Tanzu Kubernetes Grid.
• Bring Your Own Load Balancer - можно выбирать тип балансировки L4 для кластеров Tanzu Kubernetes. Первым партнером VMware стало решение HAProxy в формате виртуального модуля OVA.
• Application-focused management - теперь пользователи могут применять vCenter не только для управления виртуальными машинами, но и для обслуживания, мониторинга и траблшутинга инфраструктуры контейнеров, включая приложения и неймспейсы (подход application focused management).

2. Продолжение масштабирования возможностей платформы

В этой категории нужно отметить следующие возможности:

• Monster VMs - для пользователей решений SAP HANA, Epic Operational Databases, InterSystems Cache и IRIS компания VMware позволяет масштабировать виртуальные машин до 24 ТБ памяти и до 768 виртуальных процессоров (vCPU). То есть все ресурсы хоста могут быть предоставлены виртуальной машине, требующей их большое количество. Это было сделано за счет улучшения планировщика ESXi, а также логики ко-шедулинга для больших ВМ.

• Cluster scale enhancements - теперь в   vSphere 7 U1 кластер может содержать до 96 хостов! Это на 50% больше значения в релизе vSphere 7 (64 штуки):

3. Упрощение операций администраторов

• vSphere Lifecycle Manager - теперь vLCM поддерживает и хосты vSAN, и конфигурацию сетевого стека NSX-T. В vSphere 7 Update 1 решение vLCM также мониторит соответствие образов непрерывно, что позволяет вовремя запустить процесс обновления (remediation).

• vSphere Ideas - эта функциональность позволяет пользователям запросить возможности vSphere следующих версий прямо из интерфейса vSphere Client, отслеживать статус своих запросов, видеть запросы других пользователей и голосовать за них. Не факт, конечно, что к вам прислушаются, но общую обстановку по тому, что хотят администраторы, вы будете видеть.

• vCenter Connect - теперь пользователи могут управлять своими виртуальными ресурсами VMware Cloud on AWS или в других облаках на базе vCenter из единого интерфейса.

Доступность для загрузки VMware vSphere 7 Update 1 ожидается в рамках или после конференции VMworld Online 2020. Следите за нашими обновлениями!

Вчера компания VMware сделала сразу несколько интересных анонсов. Одним из них стало объявление о скором выпуске новой версии платформы VMware vSAN 7 Update 1, а сегодня мы расскажем еще об одной интересной вещи - обновлении VMware Cloud Foundation 4.1.

Напомним, что это комплексное программное решение, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager. О версии платформы VCF 4.0 мы писали вот тут.

Новый релиз продолжает развитие функций прошлой версии, где появилась интеграция с Tanzu, добавляя возможности в рамках подхода "developer ready infrastructure".

Давайте посмотрим, что нового появилось в Cloud Foundation 4.1:

1. Платформа vSAN Data Persistence Platform

vSAN Data Persistence предоставляет фреймворк для сервис-провайдеров, который позволяет построить глубокую интеграцию Kubernetes с нижележащей виртуальной инфраструктурой за счет метода Kubernetes operator и службы vSphere Pod Service. Эта платформа создана для партнерских решений, поэтому ее физическое воплощение мы увидим, когда кто-то из разработчиков сделает под нее свои продукты. Более подробно об этом можно почитать вот тут.

В числе первых партнеров будут:

• Cloudian
• DataStax
• Dell Technologies
• MinIO

2. Технология VMware Cloud Foundation Remote Clusters

Это специальное решение, которое позволяет расширить спектр стандартных операций в VCF на инфраструктуру удаленных офисов и филиалов. Об этом подробно можно почитать тут и тут.

3. VVols как основное хранилище VCF Workload Domain

Теперь VCF предоставляет полную поддержку своим управляющим фреймворком томов VVOls для рабочих нагрузок в VCF workload domain, включая все основные операции управления и развертывания новых виртуальных машин.

4. Функции автоматизации для vRealize Suite 8

VMware Cloud Foundation 4.1 позволит автоматически развертывать vRealize Suite 8.1. Продукт vRealize Suite Life Cycle Manager (vRSLCM) развертывается со стороны SDDC manager, а сам vRSLCM теперь знает о VCF и отвечает после установки за все компоненты, что упрощает управление программным обеспечением и развертывание новых систем.

5. Улучшения SDDC Manager

В главной управляющей консоли появилось множество небольших улучшений. Например, администраторы могут пропускать прошлые релизы и позволять кластерам NSX-T обновляться в параллельном режиме. Кроме того, в SDDC Manager появились сервисные аккаунты для упрощения коммуникаций между SDDC manager и другими продуктами в составе Cloud Foundation.

6. Поддержка VCF со стороны VMware Skyline

Служба VMware Skyline для VCF позволяет не только отслеживать и решать текущие проблемы в рамках управляющих и рабочих доменов, которые теперь видны для Skyline, но и проактивно формировать предложения по инфраструктуре VMware Cloud Foundation.

Доступность VMware Cloud Foundation 4.1 ожидается в самое ближайшее время (возможно, после предстоящего VMworld Online 2020).

Компания VMware анонсировала новую версию платформы для создания отказоустойчивых хранилищ для виртуальных машин VMware vSAN 7.0 Update 1. Напомним, что о прошлой версии vSAN 7 мы писали вот тут.

Данная версия vSAN сфокусирована на функциях по обеспечению эффективности датацентра, которые нацелены на увеличения возврата инвестиций в оборудование и программное обеспечение:

Новые возможности VMware vSAN 7 U1 можно разделить на 3 категории:

• Эффективность и производительность
• Упрощение операций с инфраструктурой хранения
• Интеграция с облачной инфраструктурой

1. Технология HCI Mesh

Главная из новых возможностей - это технология VMware HCI Mesh, которая позволяет смонтировать датасторы удаленного кластера vSAN (который выступает в роли "сервера" для кластеров-клиентов):

В такой схеме можно использовать несколько кластеров-клиентов для монтирования датастора, но надо соблюдать правило доступа: не более 64 хостов ESXi к одному датастору, включая хосты серверного кластера.

В такой конфигурации можно делать vMotion виртуальных машин между кластерами vSAN, но хранилище (Storage vMotion) при этом перемещать нельзя.

Также в топологии HCI Mesh можно использовать подход Full Mesh, когда один и тот же кластер выступает и клиентом, и сервером:

Подход Full Mesh позволит вам сбалансировать потребление емкости кластеров хранилищ. При этом есть ограничение: каждый серверный кластер может экспортировать не более 5 датасторов для клиентских кластеров, а каждый клиентский - монтировать не более 5 датасторов серверных кластеров.

Особенности технологии HCI Mesh:

• Минимальное число узлов кластера-клиента и кластера-сервера - 2 узла
• Технически Compute-only vSAN cluster (без своих датасторов) сейчас работает, но не рекомендуется к использованию и не поддерживается
• Поддерживается одновременное использование хранилищ Hybrid (SSD+HDD) и All-Flash одновременно

Небольшой обзор технологии:

2. Поддержка SMB для vSAN Native File Services

VMware расширяет службы vSAN Native File Services за счет поддержки протокола SMB. Он интегрирован с Microsoft Active Directory и поддерживает аутентификацию Kerberos. Таким образом, vSAN теперь поддерживает NFS (версии 3 и 4.1) и SMB.

3. Шифрование vSAN Data-in-Transit Encryption

Теперь в vSAN 7 Update 1 есть возможность шифрования при передаче данных между узлами кластера по протоколу TCP с использованием крипто-модуля FIPS-2. При этом вам не потребуется использовать Key Management Server (KMS).

Также надо отметить, что одновременное использование HCI Mesh и Data-in-Transit Encryption не поддерживается.

4. Техника SSD Secure Erase

В vSAN 7 Update 1 появился надежный способ удаления данных с SSD-дисков. Пока это поддерживается только для оборудования Dell и HPE. Например, это можно будет использовать для готовых серверных узлов vSAN Ready Nodes и комплектов DellEMC VxRail.

5. Общая оптимизация производительности

Как и всегда, VMware проводит работу над улучшением vSAN в контексте производительности. Заявляется, что vSAN 7 Update 1 работает примерно на 30% быстрее при выполнении операций, чем vSAN 6.7 U3 (который до этого был самым производительным).

6. Возможность использования компрессии без дедупликации

Ранее vSAN позволял использовать две этих технологии только вместе, а сейчас можно использовать только сжатие данных, не нагружая вычислительные ресурсы движком дедупликации. Теперь технология работает так:

Дедупликация

• На уровне дисковой группы
• Работает при дестейджинге данных на capacity tier
• Работа с фиксированными блоками 4 КБ

Компрессия

• Работает после дедупликации, но до того, как данные дестейджатся
• Если блок можно сжать до 2 КБ или менее, то он сжимается
• Иначе сохраняется блок 4 КБ

Компрессия работает значительно быстрее дедупликации, поэтому ее отдельно удобно использовать для OLTP-нагрузок.

7. Функция Enhanced durability при выполнении операций обслуживания

Если хост ESXi находится в режиме обслуживания (maintenance mode), то vSAN теперь имеет механизм защиты данных, которые в этот период находятся только в одном экземпляре (у них был задан failures to tolerate равный 1, а а хост перевели в режим обслуживания - и теперь есть только одна активная реплика данных).

В таком случае vSAN понимает, что у вас был FTT=1, и на время обслуживания все операции записи начинает дублировать на выделенный хост для delta writes, чтобы вы не потеряли данные во время отказа хоста с единственной копией данных:

При выходе хоста ESXi из режима обслуживания происходит обновление его данных с временного хранилища, после чего оно высвобождается для дальнейшего использования. Интересно, что для этих целей можно использовать и witness-хост.

Данный механизм можно использовать как для RAID Mirroring, так и для Erasure Coding.

8. Быстрая перезагрузка и ускоренный апгрейд кластеров

• Существенное ускорение апгрейда кластеров за счет более быстрой перезагрузки хостов
• Метаданные хоста записываются на диск перед перезагрузкой и восстанавливаются в память после загрузки - это ускоряет актуализацию метаданных
• Как результат - хосты загружаются до 5 раз быстрее

9. Общий witness-хост для нескольких кластеров

Это очень удобно для ROBO-инсталляций. vSAN 7 Update 1 поддерживает до 64 кластеров в двухузловых конфигурациях с общим witness для ROBO-сценариев (это решения для удаленных офисов и филиалов - Remote or Branch Offices).

10. Оптимизация всегда доступной емкости (Slack Space)

По рекомендациям VMware нужно было всегда держать 25-30% свободной емкости хранилищ в кластере. Это называлось Slack Space. Теперь это называется Reserved Capacity, и ее необходимый объем зависит о числа узлов в кластере (чем меньше узлов - тем меньше емкость), например:

• 12 node cluster = ~16%
• 24 node cluster = ~12%
• 48 node cluster =~ 10%

Эта емкость нужна для:

• Операций Resync при изменении политик, ребалансировке, перемещении данных (Operations Reserve)
• Активностей Rebuild при отказах хранилищ и хостов (Host Rebuild Reserve)

Надо понимать, что Reserved Capacity предотвращает только развертывание новых виртуальных машин, но не затрагивает ввод-вывод уже имеющихся.

Также Reserved Capacity - это опциональный механизм, который не включен по умолчанию:

Функция vSAN Reserved Capacity не поддерживается для растянутых кластеров и двухузловых конфигураций.

11. Улучшения vSphere Lifecycle Manager (vLCM)

Еще в vSAN 7 поддерживались узлы Dell и HPE для решения vLCM, теперь же к ним добавилось и оборудование Lenovo ReadyNode.

Сам vLCM получил следующие улучшения:

• Работа с vSAN Fault Domains, двухузловыми конфигурациями и растянутыми кластерами (Stretched Clusters)
• Предпроверки Hardware compatibility pre-checks
• Параллельное обновление кластера до 64 хостов
• Поддержка окружений с NSX-T 3.1

12. Упрощенная маршрутизация для некоторых топологий

Раньше для топологии vSAN с внешним witness должны были иметь статическую маршрутизацию. Теперь в vSAN 7 Update 1 можно добавить шлюз по умолчанию и не прописывать статические маршруты:

13. Утилита vSAN I/O Insight

С помощью этого средства можно анализировать I/O-паттерны для анализа рабочих нагрузок в кластере. Это утилита, встроенная в vSphere Client, в которой доступен большой набор паттернов метрик и гистограмм для анализа таких вещей, как R/W ratio, Seq/Random ratio, 4K aligned / unaligned ratio, IO size distribution.

Все это позволяет не пользоваться сторонними утилитами для решения узких проблем, а понимать их природу прямо из vSphere Client:

14. Улучшения сервисов для Cloud native applications

• Платформа vSAN Data Persistence - это новый фреймворк для партнеров, который позволяет интегрировать информацию о приложениях для операционных задач через API.
• SAN Direct Configuration - это альтернативный способ для прямой интеграции сервисов с хранилищами vSAN.
• Улучшения интеграции с vSphere with Tanzu за счет расширений для томов гостевых кластеров TKG, а также получения информации о состоянии томов TKG supervisor и guest.

Доступность для загрузки VMware vSAN 7 Update 1 ожидается в самое ближайшее время, следите за нашими новостями.

Компания Veeam Software, широко известная своим главным в отрасли решением Veeam Backup and Replication для резервного копирования виртуальных и физических сред, а также своими бесплатными утилитами, выпустила бесплатное руководство "Veeam Unofficial VMware VCP-DCV 2020 Study Guide", которое позволит вам подготовиться к главному экзамену на сертифицированного специалиста VMware Certified Professional Datacenter Virtualization (VCP-DCV 2020).

Напомним, что VMware недавно выпустила данную сертификацию для 2020 года и обновила основной экзамен Professional VMware vSphere 7.x Exam (2V0-21.20), который позволяет ее получить.

Руководство от Veeam на 133 (!) страницах позволит вам качественно подготовиться к сдаче этого экзамена и с помощью практических заданий отточить все основные операции по администрированию виртуальной инфраструктуры VMware vSphere 7.

Основные разделы документа:

• VMware vSphere architectures & technologies
• VMware product and solutions
• Installing, configuring and setting up a VMware vSphere solution
• Performance-tuning and optimizing a VMware vSphere solution
• Administrative and operational tasks in a VMware vSphere solution

Очень полезный документ для тех, кто готовится к экзамену, а главное - бесплатный. На страницах есть ссылки на документацию VMware по данной теме, а также QR-коды, чтобы легко переходить с распечатанного руководства на электронную версию соответствующего раздела документации.

Скачать Veeam Unofficial VMware VCP-DCV 2020 Study Guide можно по этой ссылке.

На сайте проекта VMware Labs обновилась утилита Horizon Session Recording до версии 2.1.50. Напомним, что о прошлой ее версии (2.08) мы писали вот тут.

Данная утилита предназначена для записи пользовательских сессий и активности в виртуальных десктопах и приложениях, доставляемых по протоколу Blast Extreme (PCoIP пока не поддерживается). С помощью Session Recording администратор Horizon имеет возможность перенаправить запись экрана сессий пользователей, сделанных в определенное время, на центральный сервер, где потом он может воспроизвести их в HTML5-консоли. Саму сессию в виде видеофайла можно скачать как MP4 для воспроизведения в локальном плеере.

Посмотрим, что нового в Horizon Session Recording 2.1.50:

• Добавлена поддержка новой версии VMware Horizon 8 (он же 2006)
• Исправлены проблемы с дэдлоками при записи видео со стороны агента
• Множество исправлений ошибок на стороне агента (еще в версии 2.1)

Авторы утилиты обещают скорую поддержку LDAP и интеграцию продукта в состав решения VMware Horizon.

Скачать Horizon Session Recording 2.1.50 можно по этой ссылке. Документация доступна тут.

Некоторое время назад мы писали о сервисах технической поддержки VMware Skyline (и тут). Напомним, что это проактивная технология VMware для предоставления расширенной технической поддержки некоторым клиентам для продуктов VMware vSphere.

На днях VMware аноснировала новую полезную утилиту Skyline Health Diagnostic Tool, с помощью которой пользователи смогут взаимодействовать с технической поддержкой вендора (GSS) и совмесно работать над возникающими проблемами в техническом ключе.

С помощью утилиты SHD вы сможете более эффективно работать с персоналом GSS, анализируя логи с помощью лог-бандлов для различных решений, и получать рекомендации об оптимизации виртуальной инфраструктуры:

Проще говоря, Skyline Health Diagnostics for vSphere - это утилита самообслуживания, которая позволяет идентифицировать проблемы с помощью лог-бандлов и получить ссылки на помогающие статьи VMware KB. Самое интересное, что утилита Health Diagnostics for vSphere доступна абсолютно бесплатно (за сам сервис Skyline, конечно же, надо платить).

Те из вас, кто использовал Skyline, знают, что есть такое средство Skyline Advisor, которое выполняет схожие (на первый взгляд) функции. Так зачем же нужен Skyline Health Diagnostic Tool?

Во-первых, Skyline Advisor - это облачный веб-сервис, а SHD - полноценный онпремизный тул для заказчиков. Ну а, во-вторых, Skyline Advisor - это тул для проактивной аналитики, а Health Diagnostic Tool сфокусирован на текущем анализе логов и решении проблем.

Управление утилитой Skyline Health Diagnostics происходит через веб-интерфейс виртуального модуля.

SHD выполняет следующие функции:

• На базе симптомов какой-либо проблемы представляет ссылку на Knowledge Base (где рассказано о ее исправлении), либо сразу выводит конкретные шаги по устранению трудностей.
• Механика самообслуживания ускоряет процесс самостоятельного нахождения причины проблем.
• Быстрое приведение инфраструктуры в соответствие с помощью конкретных рекомендаций позволяет оперативно устранить неполадку без нарушения процессов бизнеса.

Установка продукта разбита на 3 простых шага:

Более подробно об установке Health Diagnostic Tool рассказано вот тут, а сам процесс разобран в видео ниже:

Апгрейд виртуального модуля происходит в рамках простого рабочего процесса: надо просто зайти в Settings-> Upgrade & History.

С помощью SHD логи можно анализировать в двух режимах:

• Online - можно соединиться с сервером vCenter Server или ESXi и собрать логи. В рамках одной задачи анализа можно обрабатывать до 32 хостов.
• Offline - можно руками загрузить логи в формате .TGZ или zip-файла (когда отчеты сгенерируются, они будут доступны для скачивания.

Загрузить VMware Skyline Health Diagnostic Tool можно по этой ссылке. Документация доступна тут.

Коллега с virten.net написал замечательную статью об использовании сетевых адаптеров USB на хостах VMware ESXi, основные моменты которой мы приведем ниже.

Напомним, что подключить сетевые адаптеры USB на хостах ESXi можно с помощью драйвера USB Network Native Driver for ESXi, о котором мы не так давно писали вот тут. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.

Еще один вариант использования таких адаптеров - когда у вас (например, на тестовом сервере) есть всего один гигабитный порт, а вам нужно тестировать технологии и продукты, где нужно несколько высокоскоростных соединений.

Итак, после того, как вы скачаете драйвер, его установка делается одной командой:

# esxcli software vib install -d /path/ESXi700-VMKUSB-NIC-FLING-39035884-component-16770668.zip

На VMware ESXi 7 можно использовать фичу "component":

# esxcli software component apply -d /path/ESXi700-VMKUSB-NIC-FLING-39035884-component-16770668.zip

С помощью PowerShell можно создать кастомизированный образ ESXi с уже вшитым драйвером сетевого USB-адаптера. Просто раскомментируйте строчку с нужной версией драйвера:

# ESXi 7.0 Image with USB NIC Fling 1.6:
$baseProfile = "ESXi-7.0.0-15843807-standard"   # See https://www.virten.net/vmware/vmware-esxi-image-profiles/ for available Image Profiles

$usbFling = "ESXi700-VMKUSB-NIC-FLING-39035884-component-16770668.zip"        # Uncomment for ESXi 7.0

#$usbFling = "ESXi670-VMKUSB-NIC-FLING-39203948-offline_bundle-16780994.zip"  # Uncomment for ESXi 6.7

#$usbFling = "ESXi650-VMKUSB-NIC-FLING-39176435-offline_bundle-16775917.zip"  # Uncomment for ESXi 6.5
Add-EsxSoftwareDepot https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

Export-ESXImageProfile -ImageProfile $baseProfile -ExportToBundle -filepath "$($baseProfile).zip"

Remove-EsxSoftwareDepot https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

Invoke-WebRequest -Method "GET" https://download3.vmware.com/software/vmw-tools/USBNND/$($usbFling) -OutFile $($usbFling)

Add-EsxSoftwareDepot "$($baseProfile).zip"

Add-EsxSoftwareDepot $usbFling

$newProfile = New-EsxImageProfile -CloneProfile $baseProfile -name $($baseProfile.Replace("standard", "usbnic")) -Vendor "virten.net"

Add-EsxSoftwarePackage -ImageProfile $newProfile -SoftwarePackage "vmkusb-nic-fling"

Export-ESXImageProfile -ImageProfile $newProfile -ExportToIso -filepath "$($baseProfile.Replace("standard", "usbnic")).iso"

Export-ESXImageProfile -ImageProfile $newProfile -ExportToBundle -filepath "$($baseProfile.Replace("standard", "usbnic")).zip"
 

При установке VMware ESXi на хост, где есть только USB сетевые адаптеры, процесс может зависнуть на 81%. В этом случае почитайте вот эту статью.

Кстати, ваши USB-адаптеры лучше всего пометить наклейками. Автор предлагает указать имя хоста ESXi, MAC-адрес адаптера и его номер vusbX:

Номер виртуального vusbX не сохраняется при перезагрузках. Начиная с версии драйвера 1.6 можно закрепить MAC-адрес за нужным vusbX. Сначала найдем наш адаптер:

# esxcli network nic list |grep vusb |awk '{print $1, $8}'

vusb0 00:23:54:8c:43:45

vusb1 a0:ce:c8:cd:3d:5d

Затем сделаем статический маппинг адаптеров с использованием модуля vmkusb_nic_fling:

# esxcli system module parameters set -p "vusb0_mac=00:23:54:8c:43:45 vusb1_mac=a0:ce:c8:cd:3d:5d" -m vmkusb_nic_fling

В данной команде нужно перечислить все адаптеры через пробел (если вы вызываете ее второй раз, то нужно переуказать каждый из адаптеров, иначе маппинг сбросится).

Далее нужно проверить маппинги с помощью команды:

# esxcli system module parameters list -m vmkusb_nic_fling
Name                        Type    Value              Description
--------------------------  ------  -----------------  -----------
usbCdromPassthroughEnabled  int                        Enable USB CDROM device for USB passtrough: 0 No, 1 Yes
vusb0_mac                   string  00:23:54:8c:43:45  persist vusb0 MAC Address: xx:xx:xx:xx:xx:xx
vusb1_mac                   string  a0:ce:c8:cd:3d:5d  persist vusb1 MAC Address: xx:xx:xx:xx:xx:xx
vusb2_mac                   string                     persist vusb2 MAC Address: xx:xx:xx:xx:xx:xx
vusb3_mac                   string                     persist vusb3 MAC Address: xx:xx:xx:xx:xx:xx
vusb4_mac                   string                     persist vusb4 MAC Address: xx:xx:xx:xx:xx:xx
vusb5_mac                   string                     persist vusb5 MAC Address: xx:xx:xx:xx:xx:xx
vusb6_mac                   string                     persist vusb6 MAC Address: xx:xx:xx:xx:xx:xx
vusb7_mac                   string                     persist vusb7 MAC Address: xx:xx:xx:xx:xx:xx

Если вы хотите сделать текущий маппинг постоянным, то используйте команду:

# esxcli system module parameters set -p "$(esxcli network nic list |grep vusb |awk '{print $1 "_mac=" $8}' | awk 1 ORS=' ')" -m vmkusb_nic_fling

Также статические маппинги можно сделать и через PowerCLI. Выводим адаптеры:

PS> Get-VMHostNetworkAdapter -VMHost esx2.virten.lab -Physical -Name vusb* |select Name,Mac 

Name  Mac

----  ---

vusb0 00:23:54:8c:43:45

vusb1 a0:ce:c8:cd:3d:5d

Настраиваем маппинги MAC-адресов:

PS> get-vmhost esx2.virten.lab | Get-VMHostModule vmkusb_nic_fling | Set-VMHostModule -Options "vusb0_mac=00:23:54:8c:43:45 vusb1_mac=a0:ce:c8:cd:3d:5d"
 

Проверяем результат:

PS> get-vmhost esx2.virten.lab | Get-VMHostModule vmkusb_nic_fling |ft -AutoSize

  Name             Options

  ----             -------

vmkusb_nic_fling vusb0_mac=00:23:54:8c:43:45 vusb1_mac=a0:ce:c8:cd:3d:5d

Тестируем производительность адаптеров

В тесте используются три типа адаптеров на хосте ESXi:

• Intel NUC embedded NIC (подключен к физическому коммутатору)
• 1 Gbit StarTech USB NIC (подключен к физическому коммутатору)
• 2.5 Gbit CableCreation (кросс-соединение между хостами)

Измеряем задержки (latency) с помощью пинга (50 штук):

# ping [Address] -c 50

Результат:

Далее тестируем пропускную способность (bandwidth) с помощью iperf3. Для этого нужно сделать копию бинарника утилиты:

# cp /usr/lib/vmware/vsan/bin/iperf3 /usr/lib/vmware/vsan/bin/iperf3.copy

Запускаем сервер на первом ESXi:

# /usr/lib/vmware/vsan/bin/iperf3.copy -s

Далее запускаем клиент на втором ESXi. Тест идет 5 минут (300 секунд) с сэмплами каждые 10 секунд:

# /usr/lib/vmware/vsan/bin/iperf3.copy -i 10 -t 300 -c [SERVER-IP]

Результат:

Далее проводим операцию vMotion виртуальной машины между хостами ESXi. Результат таков:

Очевидно, кросс-соединение на адаптерах 2.5G рулит.

Проверка совместимости

Не все сетевые адаптеры USB поддерживаются нативным драйвером. Их актуальный список всегда можно найти вот тут. Вот эти адаптеры точно работают:

Адаптеры доступны в форм-факторах USB-A и USB-C. Между ними есть переходники.

Если вам нужно высокоскоростное соединение (multi-gigabit) между несколькими хостами, можно посмотреть на следующие коммутаторы:

• MikroTik CRS305-1G-4S+IN ($130 USD) - 4 порта
• MikroTik CRS309-1G-8S+IN ($260 USD) - 8 портов
• Netgear MS510TX ($260 USD) - 10 портов
• TRENDnet TEG-30102WS ($450 USD) - 10 портов

Самое быстрое и дешевое соединение между двумя хостами ESXi - соединить адаптеры патч-кордом напрямую:

Проверяйте параметр MTU size, когда включаете Jumbo Frames

Если вы меняете размер MTU на виртуальном коммутаторе, он принудительно меняется на всех подключенных к нему физических сетевых адаптерах. Имейте в виду, что эти адаптеры должны поддерживать выставляемый MTU size.

Посмотреть размер MTU можно следующей командой:

[root@esx4:~] esxcfg-nics -l
Name    PCI          Driver      Link Speed      Duplex MAC Address       MTU    Description
vmnic0  0000:00:1f.6 ne1000      Up   1000Mbps   Full   00:1f:c6:9c:47:13 1500   Intel Corporation Ethernet Connection (2) I219-LM
vusb0   Pseudo       uether      Up   1000Mbps   Full   00:24:9b:1a:bd:18 1600   ASIX Elec. Corp. AX88179
vusb1   Pseudo       uether      Up   1000Mbps   Full   00:24:9b:1a:bd:19 1500   ASIX Elec. Corp. AX88179

В данном примере MTU size настроен как 1600, что подходит для адаптеров (и работает для сети NSX-T). Если же вы поставите его в 9000, то увидите в vmkernel.log ошибки для dvSwitch о том, что такой размер не поддерживается устройством:

2020-07-19T16:10:42.344Z cpu6:524356)WARNING: vmkusb: Set MTU 9000 is not supported: Failure
2020-07-19T16:10:42.344Z cpu6:524356)WARNING: Uplink: 16632: Failed to set MTU to 9000 on vusb0

Если вы хотите проверить корректность вашего MTU size, то можно использовать команду ping с размером пакета MTU-28 байт (8 байт на заголовок ICMP и 20 байт на заголовок IP). Таким образом, для MTU size 1600 используйте число 1572:

[root@esx2:~] vmkping ++netstack=vxlan 192.168.225.10 -d -s 1572 -I vmk10
PING 192.168.225.10 (192.168.225.10): 1572 data bytes
1580 bytes from 192.168.225.10: icmp_seq=0 ttl=64 time=0.680 ms

[root@esx2:~] vmkping ++netstack=vxlan 192.168.225.10 -d -s 1573 -I vmk10
PING 192.168.225.10 (192.168.225.10): 1573 data bytes
sendto() failed (Message too long)

Источник статьи.

Иногда в кластере хранилищ VMware vSAN случается такая ситуация, что один из хостов ESXi оказывается "пустым", то есть не содержит компонентов виртуальных машин. При этом хранилища остальных хостов в кластере могут быть загружены почти полностью.

В этом случае надо посмотреть на интерфейс vSphere Client в разделе vSAN health check - там может быть такое сообщение для проблемного хоста:

vSAN node decommission state

Означает это, что хост находится в режиме обслуживания с точки зрения vSAN (Node Decommission State). При этом, например, с точки зрения хостов ESXi кластера VMware vSphere / HA он может не быть в maintenance mode. Поэтому может сложиться впечатление, что хост просто не принимает дисковые объекты по каким-то причинам.

Это состояние рассинхрона кластера vSphere и кластера vSAN. Лечится следующей командой по SSH, которая выведет узел vSAN из режима обслуживания, после чего он оживет на прием компонентов:

localcli vsan maintenancemode cancel

Также вы можете кликнуть правой кнопкой на хосте ESXi, перевести его в режим обслуживания, а потом вернуть обратно:

Это отменит и перевод в режим обслуживания vSAN, после чего хост сможет размещать дисковые объекты виртуальных машин (для этого надо запустить операцию Rebalance). Более подробно об этом в KB 51464.

На сайте проекта VMware Hans-on Labs (HOL) появились две новые лабораторные работы, посвященные новой версии продукта для создания отказоустойчивых хранилищ VMware vSAN 7.

• HOL-2108-01-HCI – What’s new in vSAN – Getting Started
• HOL-2108-91-HCI – vSAN Quick Start – Lightening Lab

Лабораторные работы VMware HoL позволяют освоить работу с различными продуктами и технологиями, проходя по шагам интерфейса. Такой способ отлично подходит для обучения работе с новыми версиями решений без необходимости их развертывания.

Напомним, что в последнее время мы уже писали об обновлениях лабораторных работ:

• 18 новых лабораторных работ (Hands-On Labs) на тему vCloud Management Platform
• Новые лабораторные работы (Hands-on Labs) на VMware vSphere 7

Первая лабораторная работа "What's New in vSAN 7" охватывает следующие аспекты развертывания и эксплуатации продукта:

• Политики хранилищ и средства обеспечения доступности (vSAN SPBM and Availability)
• Файловые службы для работы с протоколами NFS и SMB - vSAN File Services
• Хранилища vSAN Cloud Native Storage (CNS) для контейнеров кластеров Kubernetes
• Мониторинг состояния, доступных емкостей и производительности
• Облуживание и управление жизненным циклом хранилищ и виртуальных машин
• Шифрование и безопаность платформы

Вторая лабораторная работа посвящена мастеру QuickStart для пошагового создания кластера хранилищ vSAN, с помощью которого можно быстро освоить его основные настройки и конфигурации:

В конце августа компания VMware объявила о скором выпуске решения vRealize Operations 8.2, предназначенного для управления и мониторинга виртуальной инфраструктуры. Напомним, что о прошлой версии vROPs 8.1 мы писали вот тут.

В новой версии vROPs 8.2 появилось очень много всего нового, особенно связанного с созданием единой инфраструктуры для управления и мониторинга виртуальных машин и контейнеров из единой консоли. Давайте посмотрим на все это вкратце:

1. Функции Application-Aware Troubleshooting

В vROPs в последнее время быстро развиваются возможности для мониторинга инфраструктуры приложений в виртуальных машинах и контейнерах за счет пакетов Application Performance Management (APM) management packs. Это позволяет дополнить средства мониторинга компонентов инфраструктуры точными метриками, получаемыми от приложений.

Вот так выглядят средства обнаружения приложений и их параметров в решении vRealize Network Insight в виртуальном датацентре, которые далее передаются в vRealize Operations:

vRNI обнаруживает приложения и их взаимосвязи через анализ сетевых потоков, что отлично дополняет инфраструктурный метод обнаружения со стороны vROPs.

Еще одно важное улучшение в этой категории - опция "near real-time monitoring", что позволяет собирать данные в 15 раз чаще, что близко к режиму реального времени:

2. Улучшения поддержки Kubernetes

Главное улучшение vRealize Operations 8.2 - это возможности автоматического обнаружения гостевых кластеров Tanzu Kubernetes:

Второе важное улучшение - это интеграция с Prometheus через специальный адаптер, который используется большинством разработчиков для сбора метрик с инфраструктуры кластеров Kubernetes.

Ну и Management Pack for Container Monitoring теперь переименован в "Management Pack for Kubernetes".

3. Интеграции с внешними системами

Помимо более глубокой интеграции с vRNI, решение vROPs 8.2 поддерживает целую экосистему интеграции с внешними системами и облачными технологиями. Это лучше всего иллюстрируется картинкой (интеграции доступны через соответствующие Management Packs):

Тут можно отметить следующие моменты:

• Management Pack for AWS будет включать в себя аналитику емкостей EC2
• В VxRail появится 140 новых алертов
• Существенно обновятся пакеты для SNMP, NSX-T и Skyline
• Новый management pack для Flowgate (о нем мы писали вот тут)
• vRealize Operations management pack for Horizon будет доступен только для vRealize Operations Cloud

Ну и в vROPs появятся средства True Visibility Suite от купленной компании Blue Medora, теперь они будут называться vRealize True Visibility Suite. Более подробная информация об этом появится чуть позже.

4. Простота использования

Во-первых, был существенно упрощен рабочий процесс управления политиками, с которым теперь значительно удобнее работать в интерфейсе vROPs 8.2. Все операции доступны в контексте выбранных объектов:

Во-вторых, был существенно переработан стартовый дэшборд, на котором теперь можно более интуитивно найти действия для выполнения задач:

Идея состоит в том, чтобы разделить объекты и рабочие процессы. Также разделы теперь категоризированы по типу возникающей задачи траблшутинга (доступность, нехватка ресурсов и т.п.) и разделены на уровне провайдера услуг и пользователей сервисов (ВМ и приложения):

5. Прочие улучшения

Тут можно отметить следующие наиболее важные вещи:

• Интеграция с vRealize Automation (Cloud и 8.2)
• Оценка потенциала оптимизации рабочих нагрузок (прогноз результата)
• Скачиваемые отчеты об оптимизации рабочих нагрузок (workload optimization reports)
• Поддержка назначения цен для всех нагрузок (а не только vRealize Automation) с кастомизируемыми ставками
• Оценка затрат на уровне отдельных дней
• Улучшения в движке оценки стоимости ресурсов
• Метрики AWS CloudWatch API для гостевых ОС
• Увеличен масштаб для оценки корреляции метрик
• Новые страницы информации для vSAN
• Упрощенные представления контента (с функциями импорта и экспорта), а также простые представления настроек
• Кастомные шаблоны комплаенса для vRealize Operations Cloud
• Поддержка Cloud Director Service для vRealize Operations Cloud
• Новый регион Sydney для vRealize Operations Cloud
• vRealize Operations Cloud доступен на VMware Cloud Provider Hub

О доступности для загрузки VMware vRealize Operations 8.2, скорее всего, будет объявлено на предстоящем VMworld Online 2020.

Несмотря на то, что компания VMware представила версию средства для создания отказоустойчивых хранилищ vSAN 6.5 еще в 2016 году, многие крупные компании продолжают ей пользоваться. Между тем, надо понимать, что скоро браузеры отключат поддержку Flash, и все консоли на базе этой технологии (а именно на ней работает старый vSphere Web Client) просто прекратят работать (в Chrome это запланировано на декабрь этого года).

Чтобы вы могли и дальше использовать vSAN 6.5, нужно накатить патч vSAN 6.6.1 Patch 05 (вышел еще 30 июля), в котором добавлена поддержка технологии HTML5, поддерживающейся всеми современными браузерами. О возможностях vSAN 6.6.1 мы писали вот тут.

В новом апдейте vSAN 6.6.1 на базе мажорной версии 6.5 есть следующие нововведения:

• Отчеты о производительности вы можете найти в Cluster > вкладка Monitor > секция vSAN > Performance
• Добавлена панель общей информации в разделе Virtual object, показывающая размещение и доступность объектов в кластере. Также можно фильтровать список по статусу и типу объектов.
• В разделе Virtual Objects/ View data placement есть чекбокс "Group components by host placement", который дает возможность увидеть состояние компонентов данных и быстрее обнаружить потенциальные проблемы на хостах ESXi.

Также из блога VMware мы утянули вот такое видео с обзором интерфейса HTML5 для vSAN 6.6.1:

Некоторым администраторам решения для виртуализации и доставки настольных ПК и приложений VMware Horizon иногда приходится выяснять, какие фичи клиента или агента были отмечены во время установки, чтобы быть уверенным, что пользователь имеет доступ к необходимым возможностям.

Есть простой способ сделать это для VMware Horizon Agent. Нужно на Windows-машине с установленным агентом открыть ветку реестра:

HKEY_LOCAL_MACHINE\Software\VMware, Inc.\Installer\Features_HorizonAgent

Там будут перечислены установленные фичи (значение "Local"), а для не поставленных будет выставлено значение "Absent":

Такая же штука есть и для VMware Horizon Client на Windows-машине. Нужно открыть ветку реестра:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMware VDM\Client\Installer\

И там для установленных фич будут стоять единички, а для неустановленных - нолики:

Что это за фичи, вы можете догадаться по названию ключей или поискать их в гугле.

На днях состоялся релиз интересного продукта Project Antrea 0.9.1, который позволяет пользователям кластеров Kubernetes на платформе VMware управлять сетевым взаимодействием контейнеров на базе политик.

Ну а VMware Container Networking with Antrea - это новый коммерческий продукт на базе Project Antrea, представляющий собой решение для публичных и частных облаков, использующих Open vSwitch, которое позволяет управлять сетевым взаимодействием на нескольких уровнях с предоставлением поддержки со стороны VMware. Он реализует следующие функции в рамках среды Kubernetes:

1. Исполнение политик для Managed Kubernetes Services

Antrea добавляет официальную поддержку служб AWS EKS. Кроме того, Antrea улучшает поддержку сервисов Azure AKS с использованием CNI chaining и режимом трафика "networkPolicyOnly" с соблюдением политик при использовании нативного соединения.

Также решение Antrea имеет поддержку Google GKE и может быть использовано как primary CNI в Amazon и Azure для решения проблемы исчерпания IP-адресов в окружении с большим количеством небольших нагрузок в контейнерах.

2. Политики ClusterNetworkPolicy

В отличие от политик Kubernetes network policies, которые привязаны к пространствам имен, политики ClusterNetworkPolicy позволяют администраторам определять их в рамках нескольких неймспейсов. Эти политики можно упорядочивать и добавлять к ним различные действия, что упрощает применение политик как к кластеру в целом, так и к его частям.

3. Разделение политик на уровни

В Antrea есть глобальные политики (а в будущем будут нативные политики уровня неймспейсов), которые можно сгруппировать в ярус политик (policy tier). Сейчас есть 5 таких статических ярусов: Emergency, SecurityOps, NetworkOps, Platform и Application.

В будущих релизах пользователи смогут создавать кастомные ярусы и задавать порядок их подчинения. Ролевая модель Kubernetes RBAC обеспечивает контроль создания политик пользователями. Администраторы информационной безопасности могут делегировать права по созданию политик разработчикам, при этом глобальные политики остаются на контроле администраторов ИБ.

4. Улучшения мониторинга и диагностики

Antrea предоставляет набор диагностических и операционных метрик за счет средств мониторинга Prometheus и предоставляет нативные определения CustomResourceDefinitions (CRDs), чтобы наблюдать и диагностировать состояния компонентов инфраструктуры Antrea и потоков данных.

Например, Traceflow позволяет операторам проводить инъекции пакетов в данные контейнеров, чтобы убеждаться в исполнении сетевых политик, маршрутизации и эффектов инкапсуляции для трафика между сайтами. Также утилита antctl может генерировать саппорт-бандлы для диагностики проблем.

5. Интеграция NSX-T и VMware Container Networking

Решение VMware NSX-T - это полноценная платформа для сетевой защиты приложений в контейнерах, виртуальных машин и невиртуализованных нагрузок. VMware Container Networking with Antrea работает в тандеме с NSX-T, чтобы обеспечить бесшовную сетевую связность и контроль исполнения сетевых политик в кластерах Kubernetes в виртуальном датацентре.

Более подробно о решении VMware Container Networking with Antrea рассказано на этой странице.

На сайте проекта VMware Labs на этой неделе появилось несколько обновлений полезных утилит, о новых возможностях которых мы рассказываем ниже:

1. Новая версия OS Optimization Tool b1171

Последний раз эту утилиту обновляли в начале августа этого года (b1170). Напомним, что она предназначена для подготовки гостевых ОС к развертыванию и проведению тюнинга реестра в целях оптимизации производительности, а также отключения ненужных сервисов и запланированных задач.

Что интересного в этом обновлении:

• Пункт Disable Passive Polling больше не выбран по умолчанию (некоторые приложения думали, что отсутствует интернет соединение).
• Новая настройка - использовать графический драйвер WDDM для подключений через Remote Desktop.
• Новая функция поиска по оптимизациям, чтобы найти отдельные объекты. Это доступно на вкладках Optimize и My Templates.
• Добавлен сплиттер для расширения зоны дерева слева в разделе My Templates.
• Новые контролы для управления поиском Cortana и поведением окошка поиска в таскбаре.
• Новая опция для указания аккаунта администратора, чтобы выполнять операции после отработавшего SysPrep (по умолчанию это текущий пользователь, который добавляется в группу Администраторы).
• Исправлено много ошибок.

Скачать VMware OS Optimization Tool b1171 можно по этой ссылке.

2. Обновление USB Network Native Driver for ESXi 1.6

В прошлый раз апдейт этого средства (версия 1.5) выходил в апреле этого года. Напомним, что это набор драйверов для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.

Что появилось нового:

• Добавлена поддержка устройств Aquantia и Trendnet AQC111U (0xe05a:0x20f4).
• Добавлена поддержка Realtek RTL8153 (0x045e:0x07c6).
• Поддержка Realtek RTL8156 (0x0bda:0x8156).
• Поддержка постоянных маппингов MAC-адресов VMkernel на USB NIC.
• Упрощенное сохранения состояния USB NIC.
• Решена проблема со скоростью соединения для чипсетов RTL8153.
• Это последний релиз, поддерживающий ESXi 6.5.

Теперь таблица поддерживаемых чипсетов и адаптеров выглядит так:

3. Новая версия App Volumes Migration Utility 1.0.4

Эта штука позволяет смигрировать старые объекты AppStacks, в которых распространялись приложения в VMware App Volumes 2.18, на новый формат VMware App Volumes 4.0, который реализует концепцию приложений и пакетов. Подробно мы писали об этой утилите вот тут.

Обновление 1.0.4 небольшое - тут появилась только пара исправлений ошибок. Скачать апдейт можно по этой ссылке.

Вчера мы писали про анонс новой версии настольной платформы виртуализации VMware Workstation 16, а одновременно с этим было объявлено и о выходе настольного продукта для Mac OS - VMware Fusion 12. Напомним, что этот продукт был в статусе технологического превью Fusion Tech Preview 20H1 с начала этого года.

Первое, что надо отметить - это изменения цен. Вместо $159 за Pro-версию теперь придется отдать $199:

Версии Fusion Standard за $79 больше нет, вместо нее пришел на смену продукт Fusion Player (с теми же функциями), который стоит $149:

Но самый большой плюс заключается в том, что VMware Fusion Player 12 полностью бесплатен для личного использования (не на работе). Смысл этого издания в том, что оно аналогично Workstation Player на платформах Windows и Linux.

Давайте посмотрим, что нового появилось в VMware Fusion 12:

VMware сделала множество оптимизаций для новой версии macOS Big Sur - как для гостевой, так и для хостовой ОС. Архитектура Fusion также подверглась изменениям, чтобы соответствовать новой структуре Apple hypervisor API. Теперь нет необходимости в kernel extensions, чтобы запускать Fusion, что делает платформу более безопасной.

Также Fusion 12 будет полностью поддерживать macOS Catalina при доступности для загрузки, а также сразу будет совместима и с Big Sur. Для Catalina все еще будут использоваться kernel extensions, а для Big Sur контейнеры и кластеры Kubernetes будут использовать уже Apple API.

2. Улучшения работы с контейнерами и движком Kubernetes

Теперь утилита vctl может выполнять команду vctl login для постоянного логина в реестр контейнера без необходимости писать полный ULR-путь при выполнении pull для образа. Также теперь можно развертывать локальные кластеры Kind на Kubernetes. В дополнение к поддержке kind, vctl создает docker-совместимый сокет для kind без модификации за счет собственной имплементации containerd.

3. Поддержка DirectX 11 и OpenGL 4.1

Workstation 16 поддерживает запуск игр и приложений с Direct3D версии 11 (он же DirectX 11) или OpenGL 4.1. Пользователи могут выделить до 8 ГБ vRAM для гостевой ОС (для этого сама виртуальная машина должна иметь 16 ГБ или больше оперативной памяти).

Fusion 12 Player и Fusion 12 Pro поддерживают устройства eGPU. За счет это требовательные к графике задачи можно перенести с интегрированного или дискретного GPU на внешнюю графическую карту.

5. Установка из Recovery Partition с использованием APFS

Теперь была добавлена поддержка APFS для установки macOS из раздела Recovery Partition, чтобы можно было быстро разворачивать гостевые ОС Mac.

Теперь поддерживаются соединения с ESXi 7 и vCenter 7 для управления виртуальными машинами, включая их перемещение между хостами и совместимость с инфраструктурой виртуальных ПК. Это доступно только в Pro-версиях.

7. Движок рендеринга графики в песочнице

Теперь есть новая функция Sandbox Renderer, которая позволяет отделить виртуальный графический движок, дав ему пониженные привилегии, что делает платформы Fusion и Workstation более безопасными.

8. Улучшенные специальные возможности

Теперь продукт соответствует стандарту VPAT Section 508 для лиц с ограниченными возможностями.

Теперь в Fusion поддерживаются виртуальные устройства USB 3.1, их можно пробрасывать в виртуальные машины с полной поддержкой драйверов. Ну и в целом работа с USB теперь сделана по-человечески. Кроме того, было сделано множество улучшений в плане производительности, безопасности, а также исправлено много багов.

Пользователи, купившие VMware Fusion 11.5 или VMware Fusion 11.5 Pro после 15 июня, получат бесплатный ключ на Fusion 12. Доступность продукта ожидается уже в самое ближайшее время.

На днях компания VMware сделала анонс новых версий настольных платформ виртуализации Workstation 16 и Fusion 12. Напомним, что их обновления были анонсированы в продолжение технологических превью Workstation Tech Preview 20H1 (первая половина 2020 года) и Fusion Tech Preview 20H1. Сегодня мы поговорим о новых возможностях VMware Workstation 16.

С выходом новых версий поменялась и лицензионная политика. Теперь нет издания Standard, остались только Pro-версия и плеер. За $99 существующие пользователи могут переехать на новые версии Fusion Pro и Workstation Pro:

Стоимость новой лицензии для обоих продуктов стала $199 - это несколько дороже старых стандартных версий (особенно Fusion по $79), но вроде как это теперь Pro-версия для обеих платформ. Она стала дешевле для Workstation и дороже для Fusion.

Давайте теперь посмотрим, что нового появилось в VMware Workstation 16:

1. Поддержка контейнеров и Kubernetes

Для разработчиков, использующих контейнеры, появилась новая утилита командной строки - vctl. Ранее уже доступная в Fusion, она позволяет пользователям выполнять операции push, pull, build и run для образов OCI, а также развертывать локальные кластеры Kind на Kubernetes.

В дополнение к поддержке kind, vctl создает docker-совместимый сокет для kind без модификации контейнера за счет собственной имплементации containerd.

Также данная функция будет доступна и с Workstation Player.

Workstation 16 поддерживает запуск игр и приложений с Direct3D версии 11 (он же DirectX 11) или OpenGL 4.1. Пользователи могут выделить до 8 ГБ vRAM для гостевой ОС (для этого сама виртуальная машина должна иметь 16 ГБ или больше оперативной памяти).

Теперь поддерживаются соединения с ESXi 7 и vCenter 7 для управления виртуальными машинами, включая их перемещение между хостами и совместимость с инфраструктурой виртуальных ПК. Это доступно только в Pro-версиях.

4. Темная версия интерфейса

Теперь в Workstation 16 есть темная тема Dark Mode UI, доступная как в Pro, так и в Player. Эта версия отлично дополняет темную тему Windows 10 билд 2004.

5. Движок рендеринга графики в песочнице

Теперь есть новая функция Sandbox Renderer, которая позволяет отделить виртуальный графический движок, дав ему пониженные привилегии, что делает платформы Fusion и Workstation более безопасными.

На Workstation 16 для Linux теперь появилась поддержка Vulkan API. Теперь рендер может использовать DirectX 10.1 и OpenGL 3.3 даже на базе интегрированной карты Intel GPU.

7. Улучшенные специальные возможности

Теперь продукт соответствует стандарту VPAT Section 508 для лиц с ограниченными возможностями.

Теперь в Workstation поддерживаются виртуальные устройства USB 3.1, их можно пробрасывать в виртуальные машины с полной поддержкой драйверов. Кроме того, было сделано множество улучшений в плане производительности, безопасности, а также исправлено много багов.

Пользователи, купившие VMware Workstation 15.5 Pro или Workstation 15.5 после 15 августа, получат бесплатный ключ на Workstation 16. Доступность продукта ожидается уже в самое ближайшее время.

На днях компания VMware обновила пару продуктов линейки серверной платформы, выпустив обновления компонентов vSphere 6.7 Update 3:

Давайте посмотрим, что нового появилось в vCenter и ESXi:

• Поддержка SMTP-аутентификации в виртуальном модуле vCenter Server Appliance для отсылки алертов и алармов по почте в защищенном режиме. Можно также использовать и анонимный режим.
• Еженедельное оповещение о приближении устаревания сертификатов для служб vCenter Single Sign-On Security Token Service (STS). Напоминалки начинаются за 90 дней и появляются каждую неделю.
• Через Managed Object Browser можно сделать hard stop виртуальной машины на случай, если это невозможно сделать из гостевой ОС. Формат вызова такой: https://10.100.200.300/mob/?moid=vm-518&method=terminate
• Обновления базовой операционной системы Photon OS.

Release notes доступны тут.

В основном, этот релиз содержит исправления ошибок, среди которых есть и критические ошибки, приводившие к падению хоста ESXi. Полный список фиксов доступен в тут.

В основном, этот релиз содержит исправления ошибок, полный список фиксов доступен тут. Также обновился openssl до версии 1.0.2v. Пакеты VMware Tools для Windows подписаны сертификатами Microsoft на базе SHA-2.

В основном, этот релиз содержит исправления ошибок, полный список фиксов доступен тут.

Скачать VMware vSphere 6.7 Update 3 и обновленный vCenter 6.7 Update 3j можно по этой ссылке.

Обновление: вышел патч с исправлением ошибки, доступен тут.

Те из вас, кто поставил обновление VMware vCenter Server 7.0.0c, могли столкнуться с проблемой высокой загрузки CPU в виртуальном модуле (почти до 100%). Данная проблема обсуждается вот в этой ветке форумов VMware.

Выглядит это примерно так при выполнении команды top в ОС модуля vCSA:

Также во время этого компонент vAPI Endpoint показывает следующее предупреждение:

Failed to connect to 1da6ff8a-0bfd-4605-b4cc-c18ba520e95b\com.vmware.vcenter.nsxd.vapi vAPI provider.

Пока VMware работает над решением данной проблемы, ну а в случае ее появления нужно пойти в vCenter Appliance Management (https://vcenter:5480) и там завершить службу Workload Control Plane. Эффект от этого сохранится только до перезагрузки.

Дункан Эппинг пишет, что сейчас идет работа над фиксом этого бага:

Интересная штука нашлась мимоходом на портале VMware Docs, о котором мы писали здесь (обратите внимание, что среди доступных языков по ссылке есть русский). Оказывается, какие-то материалы доступны уже на русском языке. Например, информация о продукте VMware Identity Manager (он уже стал частью Workspace ONE Access), которую можно почитать вот тут.

Пока совсем неясно, какая документация, кроме как к этому продукту, переведена (по vSphere, например, ничего нет) - но это прорыв, коллеги!) Кто-то что-то знает об этом? Есть еще примеры официальной документации на русском?

На сайте проекта VMware Labs появилась очередная полезность - контейнер Docker, который называется VMware Container For Folding@Home. Надо сказать, что VMware официально не поддерживает приложение Folding@Home, поэтому утилита работает как на ваш волонтерский страх и риск.

Folding@Home — это проект распределённых вычислений для проведения компьютерного моделирования свёртывания молекул белка. В частности, вступив в этот проект, вы вносите вклад и в поиск эффективных лекарств для борьбы с пандемией COVID-19.

С помощью данного средства можно запустить клиент решения folding at home как в рамках отдельного контейнера Docker, так и в кластере Kubernetes. Также опционально можно включить или отключить поддержку GPU для клиента.

Контейнер сконфигурирован на автоматическое подключение к публичной команде Team VMware ID 52737. По ссылке http://vmwa.re/fah можно получить коллективную и индивидуальную статистику по использованию контейнера.

Скачать клиент VMware Container For Folding@Home можно по этой ссылке.

Производительность дисковой подсистемы в Linux зависит от различных параметров и настроек, одной из которых является тип планировщика для работы с потоком ввода-вывода (I/O scheduler). Если вы планируете использовать продукт StarWind VSAN for vSphere для создания программных хранилищ на базе виртуальных машин Linux (Virtual Storage Appliance), то информация ниже может быть вам полезна.

В зависимости от типа целевого хранилища, иногда целесообразно поменять используемый тип планировщика. Чтобы вывести текущий тип I/O scheduler, нужно выполнить следующую команду для выбранного устройства:

# cat /sys/block/sda/queue/scheduler
noop [deadline] cfq

В данном случае мы видим, что тип планировщика - это noop (он же none). В зависимости от версии ядра Linux, он также может быть выставлен как mq-deadline. Кстати, обратите внимание, что тип планировщика указывается на уровне отдельного дискового устройства.

Считается, что для SSD и NVMe-устройств лучше ставить планировщик none / noop, который уменьшает нагрузку на CPU, а вот для HDD-дисков лучше использовать mq-deadline, который показывает лучшие результаты по итогам синтетических тестов.

Чтобы поменять планировщик на noop для диска sdb, нужно выполнить следующую команду:

# echo noop > /sys/block/sdb/queue/scheduler

Потом надо обязательно проверить, что планировщик поменялся, следующей командой:

# cat /sys/block/sdb/queue/scheduler
[noop] deadline cfq

Но это все меняет тип планировщика на время, до перезагрузки, чтобы вы могли проверить разные планировщики и сделать тесты производительности. Чтобы сохранить эти изменения, нужно изменить файл scheduler.rules в директории /etc/udev/rules.d/

Например, если вы хотите поменять планировщик на noop для устройства sdb и установить политику "no read ahead" для него, то нужно добавить туда следующую строчку:

ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sdb", ATTR{queue/scheduler}="noop", ATTR{queue/read_ahead_kb}="0"

Рекомендуется выставлять одинаковый тип планировщика на всех узлах, где расположены хранилища StarWind VSAN. Также надо отметить, что последние версии продукта StarWind VSAN for vSphere при установке автоматически выставляют тип планировщика noop для SSD-хранилищ.

Недавно компания VMware опубликовала документ "VMware vSphere Performance with Intel Optane Persistent Memory in Memory Mode - Balanced Profile", в котором рассмотрены различные аспекты тестирования производительности постоянной памяти Intel Optane, которая работает в новом режиме Balanced Profile.

Напомним, что Intel Optane DC persistent memory (DCPMM) - эта память не такая быстрая как DRAM и имеет бОльшие задержки, но они все равно измеряются наносекундами. При этом данная память позволяет иметь ее большой объем на сервере, что существенно повышает плотность ВМ на одном хосте.

Модули DCPMM изготавливаются под разъем DDR4 и доступны планками по 128, 256 и 512 ГБ. В одной системе может быть до 6 ТБ памяти DCPMM. Платформа VMware vSphere 6.7 EP10 и более поздние версии поддерживают память Intel Optane persistent memory 100 series (она же Intel Optane PMem) со вторым поколением процессоров Intel Xeon Scalable в режимах App Direct и Memory.

В указанном документе рассматривается производительность данной памяти в новом режиме Balanced Profile для конфигурации BIOS, который впервые появился в процессорах Intel этой серии в целях повышения производительности. За счет данного режима производительность памяти увеличилась в 1.75 раза, как показано на картинке по результатам тестов:

Об остальном можно узнать из упомянутого выше документа.

На сайте проекта VMware Labs появилась интересная штука для Data Scientist'ов - средство Federated Machine Learning on Kubernetes. Техника Federated Learning предполагает распределенную модель создания систем в области больших данных средствами машинного обучения, без необходимости расшаривать тренировочный датасет с централизованной ML-системой и другими пользователями.

Проще это понять на примере - есть такие задачи, где данные нужно обрабатывать ML-алгоритмами (например, предиктивная клавиатура Gboard от Google, которая, кстати, круче яблочной), но сами данные (набранные тексты) на центральный сервер передавать нельзя (иначе это нарушение пользовательской приватности). В этом случае распределенная система Federated Learning позволяет обрабатывать модели на оконечных устройствах. Координация тренировки моделей при этом может быть централизованная или децентрализованная. Примерами также здесь могут служить такие сферы, как кредитный скоринг, медицинские данные, страхование и многое другое, где есть большие данные и строгие правила их хранения и обработки.

Практическим воплощением принципов FL является фреймворк FATE, который поддерживается сообществом Linux Foundation. Компания VMware выпустила средство Federated Machine Learning on Kubernetes, которое позволяет быстро развернуть и управлять кластером Docker / Kubernetes, который содержит в себе компоненты FATE. В такой среде можно делать следующие вещи:

• Разрабатывать и тестировать модели в Jupyter с использованием технологий Federated Machine Learning
• Построить FATE-кластер с полным жизненным циклом обслуживания, в том числе на базе платформ MiniKube, Kubernetes on AWS/Google Cloud/Azure, VMware PKS и VMware Tanzu

Утилита командной строки, которая доступна в рамках данного средства, позволяет создать и развернуть весь FATE-кластер на базе уже готовой конфигурации, которую можно кастомизировать по своему усмотрению.

Для работы с Federated Machine Learning on Kubernetes можно использовать Docker 18+ / Docker-compose 1.24+, либо Kubernetes v1.15+, также вам потребуется Linux-машина для исполнения CLI-интерфейса утилиты. Загрузить данное средство можно по этой ссылке, документация доступна тут.